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TEXT OBJECT COMPILATION METHOD AND SYSTEM 
BACKGROUND OF THE INVENTION 

Field of the Invention 

5 This invention relates to the field of software compilers, and more particularly 

relates to a method of generating files of information from one or more source files. 

Description of the Related Art 

In March, 1989, the European Laboratory for Particle Physics or CERN (Conseil 

Europeen pour la Recherche Nucleaire) developed the World- Wide- Web (WWW, or 
10 simply, "the web"), an Internet-based computer network that allows users on one 

computer to access information stored on other computers, through a world-wide network. 

With an intuitive user-interface, known as a web browser, the web rapidly became a 

popular way of transmitting and accessing text and binary information. Since then, there; 

has been a massive expansion in the number of World-Wide- Web sites, and the amount of 
15 information placed on the web. 

Information, in the form of electronic files, documents, images, sounds and other 

formats, forms the basis of internet and web content, and the key to creating a useful and 

meaningful web-site. 

To place information on the web, the information must be stored in a binary or — • 
20 text format in a "file." Binary documents are saved in known formats that depend upon 
the information being stored. For example, two-dimensional pictures are often stored in 
"Joint Photographic Experts Group" (JPEG) or "Graphical Image Format" (GIF) standard 
formats. Audio files and moving images have other formats as well, such as "WAV," 
"MOV," and "MPEG." For text documents, documents are stored in a HyperText Markup 
25 Language (HTML) format. The HTML format dictates the appearance and structure of a 
web text document, also referred to as a "web page." 

Although these formats are required to create compatibility for web browsers, 
modifying web sites and updating information in these rigid formats is difficult and time 
consuming. For example, suppose every web page had a copyright notice on it. To 
3 o update the copyright notice on every page, a web-site administrator would have to either 
change every page by hand, or use a method of global-search-and-replace. However, . 
because of the non-uniform manner of sotme web-sites, a global-search-and-replace may 
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not work. More complicated web page changes, such as modifying small applications, 
known as "applets," are even more difficult. It would be much better if there was a single 
location or file that could be updated, and the change would be propagated to the entire 
web-site, or just the appropriate web pages. Very simply put, the problem of maintaining 
and generating large amounts of data, in any format, is difficult and highly time 
consuming. 

Several solutions have been proposed, each has its problems. 

Some web developers choose to generate web pages through a "what you see is 
what you get" (WYSIWYG) web-page editor. Such editors assemble web pages through 
a graphical inter face, which makes designing pages simpler, but the results are limited 
because it does not solve the need to maintain the information. Using the above example, 
to update the copyright notice on every page, a web-site administrator would still have to 
edit the web pages individually, or the web-page editor program may use a method of 
global-search-and-replace. 

Alternatively, simple pre-processor programs have been used to assemble HTML 
files. Such pre-processors allow web-page designers to pre-process documents and insert 
listed documents into a master document. For example, to include another listed 
document file called "foo.doc" into the master document, a web-page designer could type: 

tinclude "f;oo.'do,G". : ..• ' • - * 
and the listed document would be included. While this allows fragments of common 

HTML code to be inserted into documents, as a web-site grows, and more pages are 

added to the site, the maintenance of such a system quickly becomes a logistical 

nightmare. Also, the fragments cannot be redefined at the point that they are included in a 

document. Moreover, such a system is limited strictly to text-based documents, and 

cannot handle binary forms of information. 

U.S. Pat. No. 5,181,162, issued January 19, 1993 to Smith et al. entitled 

"Document management and production system," incorporated herein by reference, 

discloses a system of decomposing dpcuments into logical components, which are stored 

as discrete "objects" in anpbject-oriented computational environment. The system relies 

on queries to a relational database which occur ,every time the document is printed, 

displayed electronically, or electronically transmitted* For a web site, which may transmit 

pages thousands o^ times per ; minute, this solution is a burden on the web servers 

computing resources. .Consequently, the system would be slow, and of limited usefulness 

to such a high-demand environment. Similarly, the use of a relational database to deliver 
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pages of information on client machine^ has been attempted; while this provides dynamic 
construction of documents when they are delivered to the client machines, this solution 
also burdens the server's computing resources because page information would be 
constantly regenerated. Although caching generated pages may solve some of the 
computing resource problems, it creates a new problem because cached pages may be 
outdated. 

Several related patents, U.S. Pat Na 5*668;999, which issued September 16, 1997 
to Gosling ("System and method for preveri%#ion offstack usage in bytecode program 
loops,"), U.S. Pat No. 5,692,047, issued to McManis^ -System md method fo 
verifiable. programs, with facility for using non-yerifiable programs from trusted sources,") 
and U.S. Pat No. 5,706,502, issued to Foley et al. ("Internet-enabled portfolio manager 
system and method,"), all incorporated herein by? reference',* also fail to solve the problem. 
Collectively, these patents disclose a method and system of verifying the integrity of 
computer programs written in a bytecode language to run applications remotely on a 
client workstation. While this solution may create, dynamic client-machine applications, ; 
itdoes not solve the problem of maintaining information in a. system. . 

What is needed is a more flexibleiway , of handling berth binary and text 
information that can produce files of different: file fonnaits ahdb still be easy to maintain. 

The invention, a Text Object Compiler method, allows users to abstract 
information, and produce information in virtuMly my file format. 

Almost every contemporary computer is a register-based Von Neiiman computer 
that responds to a machine language. These machine languages include instructions 
which operate on the contents of registers. Originally, computer software instructions 
were organized in terms of machine language operations. As computers became more 
complex, programming in machine language became difficult and increasingly 
cumbersome. Consequently, computer scientists abstracted machine instructions, creating 
higher-level languages, known as source languages, structured in terms of expressions and 
procedures. As software evolved, two strategies for converting source languages into 
instructions in machine language developed, interpreters arid compilers. 

An interpreter, written in the native machine language, configures the computer to 
execute programs wri tten in one of the sburce ikngii%es. 'The primitive operators or 
commands of the source language are implemented as ^ W libra[ry"6f subroutines Wri 
the native machine language of the given machine. Interpreters read the source language, 
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one line at a time, and then perform the specified operation. A program to be interpreted, 
the source program, is represented as a data structure. The interpreter traverses this data 
structure, analyzing the source program. As it does so, it simulates the intended behavior 
of the source program by calling appropriate primitive operators from the library. 

Instead of analyzing and translating the source program into machine language 
during execution, it is possible to perform these tasks before execution, enabling more 
efficient program execution. Tliisalternate method of converting source languages into 
instructions is called compilation. The program that does the analysis of the source 
program and reduces the source program to machine language is called a compiler. As 
shown in FIG; 1, a conventional' (i-^e.; prior art) compiler 2 for a given source language 
and machine translates computer source code 1 (i.e., a program written in a high level 
"computer language") into an object code 3, a program written in the computer's native 
language, referred to in the art as machine language.*' 

Illustrated by FIG. 2, a conventional compiler 2 is composed of a lexical analyzer 
10, a parser 20, and code generator 30. A lexical analyzer 10 takes computer source code 
1 and divides the code into lexical tokens. Such lexical tokens can be based on 
instructions or other keywords in the relevant high level computer language. A parser 20 
takes the tokens and groups them together logically based oh the relationships established 
by the source language and the computer source code 1. Lastly, a code generator 30 takes 
the relationships established by the parser 20 and translates them into an executable 
computer object code 3 in computer machine language. 

Conventional compilers are well known in the prior art, such as U.S. Pat. No. 
5,560,015 ("Compiler and method of compilation" issued to Onodera on September 24, 
1996), U.S. Pat. No. 5,442,792 ("Expert system compilation method" issued to Chun on 
August 15, 1995), and U.S. Pat. No. 5,768,592 ("Method and apparatus for managing 
profile data" issued to Chang on June 16, 1998) all incorporated herein by reference. 

Conventional interpreters and compilers convert high-level computer source code 
into object code to be executed on : a computer. In effect, the interpreter and the compiler 
allow computer programmers to write computer programs at a higher level of abstraction, 
' and generate object code. ; 

SUMMARY OF THE INVENTION 

The invention, a Text Objept Compiler (TOC) method and svstem, applies this, 
same level of abstraction to information as a conventional compiler applies to computer 
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programs. A user designs abstract source code which is compiled into a file or a plurality 
of files, which is not object machine language code. Instead, the TOC produces 
information in virtually any information format, as text or binary files. The TOC reads 
one or more source files written as a Text Object Language (TOL) in ASCII text and 
processes the source files into one or more output, files in anydocument format. The 
compilation process reorganizes the information in the source files into output document 
formats, and may contain compile-time utility commands to facilitate the document 
generation process. 

In the first embodiment, a lexical analyzer tokenizQS a source input written in TOL 
regular expressions to produce a token representing, the, spurce input. Such TOL 
expressions may contain variables, functions, and classes. , A parser determines the 
relationships between the tokens so that a page generator can evaluate the tokens and the 
relationships between the tokens to generate an output ,The resulting output may be 
written as a file at a target location specified by the source input. 

In another aspect of the invention, .the source input is lexically analyzed to 
produce tokens representing regular expressiqn&^Qf the source input. The regular 
expressions are written in the Text Qbj pet Language and may include variables, functions, 
and classes. The regular expressions ^e parsed tQ determine t^ between the 

tokens. For instance, any class relationsWp be^een within this step. 

Finally the tokens and relationships are evaluated-to generate a. non-executable output. 
The non-executable output may then be written to a file. The file location may be 
specified by the original source input as a specific target location. 

In the preferred embodiment of the present invention, the source input, written 
regular expressions of a Text Object Language, is initially read. The regular expressions 
contain page definitions used to determine the output of the process, and may additionally 
contain variables, functions, target locations and object-oriented classes. Once read, the 
source input is lexically analyzed to produce token representations of the regular 
expressions, which includes tokens generated from the page definitions. The tokens are 
parsed to determine the relationship between the tokens,. and the resulting relationship is 
constructed in computer memory. Each variable and function is. evaluated and their value ~ 
is determined. The determined value replace their corresponding variable or function 
token in computer memory. The non-executable file based on the computer memory 
representation of the page tokens is then written to a file at a target location specified 
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within the source input. r . r / 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, features, and advantages of the present invention 
will be better understood in view of the following detailed description made in 
conjunction with the accompanying drawing in which: 

FIG. 1 diagrams an overview of the conventional compiler process (prior art); 

FIG. 2 illustrates the basic components of a conventional compiler (prior art); 

FIG. 3 diagrams an overview of the Text Object Compiler (TOC) process; 

FIG. 4 illustrates the basic components of a Text Object Compiler; 

FIG. 5 is a flowchart of the lexical analysis and parsing subprocesses used by the 
Text Object Compiler. 

FIG. 6 is an inheritance diagram of the classes of the Text Object Language source 
file listed in Table 3; 

FIG. 7 is an inheritance diagram showing the relationship of class variables and 
the classes;. 

FIG. 8 is an inheritance diagram showing the relationship of class functions and 
the classes; 

FIG. 9 is an inheritance diagram. consolidating the classes with their functions and 
variables; 

FIG. 10 is an inheritance diagram showing the relationship of the defined pages 
and the classes;. - - - ■ 

FIG. 1 1 diagrams the baseclass information used to generate the target document 
"first.txt"; , 

FIQ. 12 diagrams the baseclass, and myctass information used to generate the 
target document "second.txt"; 

FIG. 13 diagrams the baseclass, myclass, and newclass information used to 
generate the target document " third.txt" ; and 

FIG. 14 is a flowchart detailing the page generation subprocess. 

DETAILED DESCRIPTION OF THE INVENTION 

The Text Object Compiler uses a variety'of existing programming and compiler 
.methods that are commonly used in programming languages to create executable files. 
The unique aspect of TOC is chat it is appiiedio crieating non-executable files, which are 
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referred to as "target documents." As shown in FIG. 3, source files 101, written in a Text 
Object Language (TOL) are compiled by the TOC 102 to produce target documents 103 
as output. The target document locations are definable by the programmer, and the 
location is referred to as a "target location." Target documents 103 can be any type of 
format, and can even produce other source files used by other compilers or programs. 
The TOC 102 actually knows nothing about the format of the target documents 103; the 
target document format is solely up to the programmer. 

Reference will now be made in detail to the preferred embodiments of the 
invention, examples of which are illustrated in the accompanying drawings. While the 
invention will be described in conjunction with the preferred embodiments, it will be 
understood that they are not intended to limit the invention to those embodiments. On the 
contrary, the invention is intended to cover alternatives, modifications and equivalents, 
which may be included within the spirit and scope of the invention as defined by the 
appended claims. 
The Text Object Language (TOL) 

In the preferred embodiment, the source file or files are written in a Text Object 
Language, which when compiled or interpreted will result in at least one target file. A 
listing of some of the TOL operators is provided in Table 1. 



Operator 


Description 




The equality operator tells the compiler to 
define the keyword bri the left-hand-side of the 
operator as the value on the right-hand-side of 
the operator. For example, the usage " 
length := would define the variable 
** length" with the value of 5. 


n 


This operator indicates to the compiler the 
presence of a comment-line. The compiler 
ignores the remainder of the line. 


♦include :- filename 


Imports a source file named " filename" for 
compilation. 


class classname := baseclass 


Defines a page class. Classname must be 
specified. Baseclass, if omitted, is assumed to 
be the base class for TOL. 

A class inherits ^11 of the variables and 
functions of its base class. Classes can be 
public? private, pi -protected- - r A class can 
declare other classes as friends; a friend class is 
giveri v pUbli6 % 1accesSib ; ^T'oT the declaring class 7 1 
variables,and functions. .Within a class, . - : 
variables or functions can be declared friends. 
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Cle ax targets :«* directory 



Clears all targets previously inline. 
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Dabug := [on/ off) 


, ; Enables/Disables debug while compiling. 
The default is to stop the debugger from source 
code. 


time iclassname) : = name (varl, ... , 

varN = value) 
endfunc 


Begins a new function. If classname is 
omitted, then the class is assumed to be the base 
class. The function name, name, must be 
unique for a class. The function can contain 
zero or more variables, varl, varl, etc. 

Functions can be overloaded, with several 
functions of the same name, but with different 
number of variables; overloaded functions 
must contain a unique number of variables. 

Functions can be public, private, or 
protected. 

Functions can be made virtual, forcing them 
to be defined in a derived class. Once a 
function is declared virtual, all derived class 
instances of the function are virtual. 

Functions can contain a default value, for 
example, varl —default. 

Endfunc ends a function section. 


lfcr := ion/off) 


Enables/Disables output file wrapping. 


page iclassname) := filename 
endpage 


Begins a new page section. If classname is 
omitted, then the class is assumed to be the base 
class. The compiler builds an output page for 
each page/endpage section. Within this section, 
all variables and functions are resolved. 
Filename is the fully qualified location of the 
output file. 

Endpage ends a page section. 


targets iclassname) 
end targets 


Targets allow pages output be directed to 
different or multiple locations. Example targets 
include any media or memory storage device, 
such as disk drives, networked drives, FTP 
locations, memory cards. 

Endtargets ends a target section. 


vars iclassname) 
endvars 


Begins a new variables section. If classname 
is omitted, then the class is assumed to be the 
base class. 

Variables can be public, private, or 
protected. 

Variables can be made virtual, forcing them 
to be defined in a derived class. Once a 
variable is declared virtual, all derived class 
instances of the variable are virtual. 



Table 1. TOL Operators 

The TOL is similar to other programming languages, in that it has variables, classes, 



functions and subroutines, but uses a language syntax recognized only by the TOC 102. 

• • " : ST ■ -. 
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In addition, to the TOL operators, a number of compile-time utility commands exist to 
facilitate the document generation process 
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Utility Command 


Description 




Causes the system to sound beep with 
duration of length in milliseconds. The default 
duration is 1 00 milliseconds. 


chcUr :» path 


Changes the current directory to path. Any 
reference to a path or filename that does not 
include a drive letter will default to the current 
drive, "chdir" is executed by the compiler 
inline. 


Chdrive := driveletter 


Changes the current drive. Any reference to a 
pdin or iiiename inai aoes noi lnciuae a unve 
letter will assume the current drive "chdrive" i<; 
executed by the compiler inline. 


copy := source, destination 


Copies source to destination when the 
compiler reaches this inline command. 


exoc : = program 


Runs the specified application in program. 


kill := filespec 


Deletes the files specified in filespec. 


md :** path 


Creates the directory path. 


rd :» path 


Removes the directory path. 



Table 2. TOL Compile-Time Utility Commands 
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An exemplary source file 101 written in the Text Object Language of Table 1 can 
be seen in Table 3. 



//define the class structure and relationships 
class myclass := baseclass 
class newclass : = myclass 

//variable* definitions' 

//baseclass variables - ? . :;. 
vars 

title :« This, is my document . .title 
' endvars ■ • 

//variables for myclass • pagas ;.pn.ly 
vars (myclass) 

title := This is the document title for myclass 
endvars . 

//functions ; - ■ ■ . 

//baseclass function example 
func:=myfunc (varl, var2) 

<Hl>varl</Hl> 

<H2>var2</H2> 
endfunc " * ■ " ; ' '"" 

//function for newclass pages only 
func (newclass) : =myf unc ( varl , var2) 
<center> 

varl<br>- - ■ ■' • 
var2 
</center>- ; 

endfunc 

//target documents . . ■ . • 
page : =f irst . txt 

myf unc (title, , This is . a base, class example), 
endpage * 

page (myclass) :=second.txt 

myf unc (title, This is a myclass example) 

endfunc 

page (newclass ) :=third.txt 

- myf unc (title, This is a -newclass example) . 
endpage 

//target locations 
targets 

Local Drive := c:\web 
LAN Drive := n:\web 

Live Site := ftp://www.netcreate.com/web/html 
Endtargets 



Table 3, Example Source File written in the Text Object Language ("mysource.txt") 
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As illustrated in the example Text Object code source file 101 of Table 3, there are 
five primary components of TOL: classes, variables, functions, pages, and targets. 
Although the concepts of classes, variables, and functions exist in prior art computer 
languages, the additional concepts of pages and targets exist in the Text Object Language. 
5 TOL classes are similar to and share many of the elements of common Object 

Oriented Programming (OOP) classes. Classes allow a document programmer to 
organize document sections into objects that can be reused throughout the source files and 
applies to any of the target files. Specifying classes is optional, since a default class, or 
"base class," is always assumed. A "derived" or "child" class inherits all of the 

10 variables and functions of its base or " parent" class. 

Classes can be public, private, or protected. Public classes allow their functions 
and variables to be redefined by other classes. By default, all classes are public. Private 
classes allow their functions and variables to be redefined only by other member or friend 
classes. Protected classes allow its variables and function to be used only by member 

15 functions, friends of the class in which it is declared, and by member functions and 

friends of classes derived from the protected class. In addition, a class can declare other 
classes as friends; a friend class is given public access to all of the declaring class' ~* 
variables and functions. ■ ' 

Variables allow the source file programmer to represent elements of a target 

20 document by reference, and use the reference to create sections or target documents rather 
than using the actual data. Like classes, in the preferred embodiment, variables can be 
can be public, private, or protected. Variables can also be made virtual; forcing them to 
be defined in a derived class; however, once a variable is declared virtual, all inherited 
class instances of the variable are virtual. Note that no virtual variables of the class may 

25 exist within the program until the virtual variable is defined by the derived (child) class. 

A function is a convenient way to encapsulate some computation, which can then 
be used without worrying about its implementation. Functions allow programmers a 
conceptual way to abstract a recurring procedure without worrying about the details. 
Functions are similar to typical programming subroutines. Like classes and variables, 

3 o functions can be public, private, or protected. 

Function name overloading allows multiple function instances that provide a 
common operation on different argument types to share a common name. Functions can 
be overloaded, with several functions sharing the same name, but each having a different 



BNSDOCtD: <WO 0017748A1_L> 



WO 00/17748 



PCT/US99/21940 



number of variables. Each overloaded function :nust have a unique number of variables, 
which allows the compiler to distinguish between each instance of the overloaded 
function. Functions can be made virtual,.forcing them to be defined in a derived (child) 
class. Once a function is declared virtual, all derived class instances of the function are 
virtual. A virtual baseclass function is also virtual in the derived class if inherited by the 
derived class; such a function is treated as an abstract class, and no objects of the class 
may exist within the program until the function is defined by a derived class. 

Pages are unique to the Text-Object Language; page parameters instruct the Text 
Object Compiler 102 how to combine or parse source files 101 into the actual individual 
target documents 103. A page defines the starting and ending point of a resulting target 
document 103, and the contents of the target document 103. 

Targets are also unique to the Text Object Language. Target parameters define 
the target location; once defined, the target parameters instruct a Text Object Compiler 
102 on where to place the target documents. This location is referred to as the "target 
location;" . The target location may be local to the computer running the TOC 102, or at a 
remote location that can be accessed over a computer network by the computer. If the 
source files 101 define multiple target locations with the target parameter, the TOC 102 
will produce identical target documents 103 at each target location. Multiple targets are 
useful for creating experimental: output, creating backup files for redundancy purposes, 
and updating main/production: server files. For example, a programmer may define two 
targets to create a primary web^site and its "mirror" web-site at an alternate location. If 
target parameters are omitted from the Text Object code 101, the target documents 103 
will be created in a default local location. 
The Text Object Compiler (TOC) 

The Text Object Compiler 102 performs the compilation of the text object 
language source files 101, resulting in target documents 103 defined by the pages 
parameter as output at a target location defined by the targets parameter. As discussed, 
target documents 103 may be in any format; note that this distinguishes the TOC 102 
from prior art software compilers that which only produce object machine language code, 
i.e. executable files: Note, however, that programmers define the output format of the files 
with their source pro-am code 101. V^; 1 , 

Attention wilLnbw.be given;to the TOC structure and. method. ' :•: '-■ 
> ..The TOC 102 isisimilarvin structure to a conventional compiler. Like a * * 
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conventional compiler, the TOC contains a lexical analyzer 10 and a parser 20. However 
unlike the TOC, a conventional compiler, shown in FIG. 2, feeds parser output into a 
computer code generator 3, to generate executable computer object code 3. As illustrated 
in FIG. 4, in a Text Object Compiler 102, the parser 20 output is presented to a page 
generator 200 to produce the target documents 103 as output. 

The TOC lexical analyzer 10 examines expressions in a similar fashion to a 
conventional compiler lexical analyzer. This division into units, known as "tokens," is a 
process known in the art as "lexical analysis." Essentially, the lexical analyzer looks for 
regular expressions. A regular expressionis a>pattenx description using the computer 
language. The lexical analyzer performs as: many regular expression matches as possible, 
and attempts to classify the text of the entire source file into tokens. In the Text Object 
Language, the expressions may include variable names; function names, class names, 
target locations, page definitions, constants, strings, operators', punctuation, and so forth. 
For example, when compiling ithe source file in Table<3, ! the compiler initially classifies 
each instance of a known operator (as listed in Table l;) as a* known token; However; if 
the word or expression is unknown to the compiler^ ittoo4s still tokenized, but its value 
or relationship must still be determined by the parser, ^^.t.::.:/ ~ 

■I -. As the input is divided into tokens^itKe^compilerinust establish- the relationship 
between the tokens. The Text Object Compiler needs, to find the expressions, statements, 
declarations, blocks, functions/procedures, class structures; and pages in theprogram, a 
process known as "parsing." The list of rules that define the relationships that the T 
compiler understands is called grammar. The grammar of an exemplary Text Object 
Language is shown above in Table 1. 

The Text Object Compilation process is best explained by example. An existing 
source file 101, such as the example in Table 3 is written in the Text Object Language. 
The compiler reads the source file- as illustrated in step 250 of FIG 5. In its process of 
compiling the source code, a compiler performs two tasks over and over: a.) dividing the 
input source code into meaningful units (step 260), and b.) discovering the relationship 
between the units (step 270). These two processes are respectively called " lexical 
analysis" (step 260) and "parsing" (step 270). If the parser cannot determine the 
relationship of the token, it next determines whether the end of th^source file has been 
reached, step 280. If the end of the source file has been reached {step 280), the 
undetermined tokens: are an erro:: in either syntax or n sage, and ar_ eivor is reported, step 
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282. If the end of the source file has not been read, the compiler loops back to step 250, 
and reads the source file. Similarly, if the parsing of step 270 is successful, and the entire 
file has not been read, as determined by step 284, the compiler continues to read more 
lines of the source file, step 250. 
5 An example of the lexical analysis and parsing steps are as follows. The compiler 

initially reads the first line of Table 3, step 250. Each word is tokenized, and matched 
against a known set of regular expressions, such as the TOL Operators. The first known 
operator, the comment operator ("/A*,) is identified, step 260. As defined by the 
implementation of this TOL grammar, the remainder of the line is determined to be a 

10 comment, and the compiler ignores the remainder of the line, step 270. Since the end of 
the source file has not been reached, as determined by step 284, the compilation process 
continues, and the compiler reads the next line of the source file, step 250. 

The lexical analyzer notes the presence of four tokens on the second line, the 
words "class," "myclass" ":- 'and "baseclass." Step 260. Two of these tokens, 

is "class" and the equality operator (" :-") are identified as operators, and a third token, 

"baseclass" is identified as the "baseclass" keyword, which defines the TOL base class. 
The token "myclass" is initially unknown by the lexical analyzer. The token information 
is forwarded to the parser,which realizes that the source file defines a child class 
"myclass" which descends from the TOL baseclass, step 270. The parser constructs a 

20 memory table; memory tree, or equivalent memory structure: to categorize the class 
structure. The process is repeated with the next line, resulting in a class inheritance 
relationship depicted by FIG. 6. Class myclass 310 is derived from the base class 300, 
and class newclass 320 is a "child" class derived from the "parent" class myclass 310. 
The memory tree is expanded to reflect the newclass class. 

25 The compiler processes the next several lines of Table 3, which consist of variable 

definitions for the variable "title." The variables are parsed and stored in the memory 
tree, linked to their appropriate class definition, as shown by FIG 7. The baseclass 300 is 
associated with a variable "title"3Gl. Similarly, myclass 310 is associated with a 
different definition for another variable called " title" 311., 

30 FIG 8 . illustrates the relationships of the functions declared with their defined 

classes. The code in Table 3 defines a "myfiihb" function that is different for the 
baseclass 300 anAriewclass 320; consequently, a myfunc 302 is associated with the : 
baseclass 300, and:a different myfunc322 function is associated with newclass 320. 
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FIG 9. consolidates the inheritance diagrams with their related variables and 
functions. Baseclass 300 has both a variable, title 301, and a function, myfunc 302. The 
class myclass 310 also has a variable, title 311, and since it does not have a definition for 
myfunc, it inherits the function definition for myfunc 312 from the baseclass 300 
definition of myfunc 302. Similarly^ the class newclass 320 does not have a value for the 
"title" variable, and thus inheritsits:definiliQn'i6r.title321:toih the 1 myclass title 
definition 311. Newclass 320 does have its own* definition Tor thejfiinction myfunc 322, 
and this is also reflected in the iiiheritanee diagram. "') o;r no nv, n 

The lexical analysis and parsingiproeessjis repeated for both the target document 
and target location: sections of the code. -Asshowrrin FIGu tO^ the target document 
"first.txt" 400 is of the baseclass 300, "second.txt" 410 is.of class myclass 310, and 
"third.txt" 420 is of class newclass 320. Each of the three: target documents consist of a 
single function calico the appropriate class functions" myfunc ;*? > 

Once all the source files have been tokeiiized: arid parsed to known values, the 
established token and relationship information is passed to rthe compiler page generator, 
step 286. r ■■ -.A '"^ck-^ari " -vU c-. 

.As shown previously in FIG. 4, the compiler page generator 200 creates each 
target document based on the relationships^and tokens forwarded, from the parser 20, 
replacing variables with their approprime .value§r;evaluatmgffunction calls, and 
substituting the resulting information into ,the;page table shown in FIG. 10. 

The page generator sub-process is elaborated in FIG. 14: The token relationship 
information is passed to the compiler page generator, step 286. For each page class, the 
variables are replaced with their respective definitions, step 288. In a simple 
embodiment, this can merely be the substitution of the value into each memory table 
location where the variable appears. Each function call for every page class is then 
evaluated, step 290. The existence of each named target location is verified; if the 
location, such as a directory, does not exist, it may be created at this time by the compiler, 
step 292. Each page, corresponding to a target document, is then written at each target 
location, step 294. Lastly, the write iSiVerified by the: compiler, step 296. 

For example, as illustrated iij FIG. 11, the output for "first:txt"400 is generated by 
noting the appropriate class, baseclass 300, which defines the functions and variables. used 
in generating the page. Table 3 defines " firsttxt" as a p^ge generated by a function call 
to "myfunc" using the "title" variable ; and -Thisds a 1 base class example" a$ the input 
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Since " firsttxt" is of class baseclass, the definitions for "title" and "myfunc" are taken 
directly from the baseclass. The results are shown in Table 4. 



<Hl>This 


is 


my document title</Hl> 


<H2>This 


is 


a base .class example</H2> 



Table 4. Compiled output for "firsttxt 1 



FIG. 12 continues the compilation for "secondtxt" 410, which is of class 
5 "myclass" 310. The definitions for "title" is taken directly from class myclass 310. The 
definitions for "myfunc r * would normally also be taken from class myclass 310. 
However, since "myfunc" is not defined for myclass 310, the myfunc function definition 
for myclass' parent class, baseclass 300, is used. The compiled results for " second.txt" 
410 are shown in Table 5. 

<Hl>This is the document title for myclass</Hl> 
<H2>This is a myclass example</H2> 

io Table 5* Compiled output for "second.txt" 

FIG. 13 continues the compilation for "third.txt" 420, which is of class 
"newclass" 320. The definitions for "title" and "myfunc" are normally taken directly 
from class newclass 310. However, since the "title" variable is not defined for newclass 
320, the "title" variable definition for newclass ' parent class, myclass 310, is used. Since 
is "myfunc" is defined for the class newclass 310, the newclass "myfunc" definition is 
used. The compiled results for * third. txt" 420 are shown in Table 6. 

<center> 

This is the document title for myclass<br> 
This is a newclass example 
</center> 

Table 6, Compiled output for "third.txt" 

Once the compiler generates each page in memory, each page is written as a target 
document at each target location. The compiler may optionally create previously non- 
20 existing target locations, and verify the writing at the target locations; in its most 

preferred embodiment, the TOC performs both actions, reporting a warning message if a 
target location is not created, or an error message if a problem in writing the target 
document qccuts. 
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CLAIMS 

We Claim: 

1. A computer comprising: 

a. a lexical analyzer that tokenizes a source input to produce tokens 
representing regular expressions of the source input; ? 

b. a parser that determines relationships between the tokens; . 

c. a page generator that evaluatesfthe tokens and the relationships between 
the tokens to generate an output, the output being non-executable. 

2. A computer of claim 1 wherein the page generator .writes the output as a file. 

3. A computer of claim 2 wherein the page generator writes the file at a target 
location specified within the source input. 

4. A computer of claim 1 wherein the regular expressions include variables. 

5. A computer of claim 1 wherein the regular expressions include functions. 

6. A computer of claim 1 wherein the regular expressions include classes. 

7. A computer of claim 1 wherein the regular expressions include variables, ~ 
functions, and classes. 

8. A method of operating a computer system to compile a Text Object Language 
comprising: . .. , - 

lexically analyzing a source input to produce tokens representing regular 
expressions of the source input; " ' ' ~ 

parsing the tokens to determine relationships between the tokens; 

evaluating the tokens and the relationships between the tokens to generate a non- 
executable output. 

9. A method of claim 8 further comprising: 
writing the non-executable output to a file. 

10. A method of claim 9 wherein the file is written at a target location specified within 
, the source file. 

11. A method of claim 8 wherein the regular expressions include variables. 

12. A method of claim 8 wherein the regular expressions include functions. - 

13. A method of claim 8 wherein the regular expressions include classes. 

14. A method of claim 8 wherein the regular expressions include variables, functions, 
and classes. 
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15. A method of operating a computer system to compile a Text Object Language 
comprising: 

reading a source input containing regular expressions of the Text Object 
Language, wherein the regular expressions of the text object language include variables, 
functions, and page definitions; 

lexically analyzing the source input to produce tokens of the regular expressions, 
wherein the tokens include page tokens; 

parsing the tokens to determine relationships between the tokens; 

constructing a representation of the tokens and their relationships in computer 
memory; 

evaluating the tokens that represent variables and functions to determine their 
evaluated values; 

replacing the computer memory representation of the variable tokens and the 
function tokens with their evaluated values; 

writing non-executable files based on the computer memory representation of the 
page tokens. 

16. A method of claim 1 5 wherein the non-executable files are written in a target 
location specified by the source input. 

17. A method of claim 15 wherein the regular expressions include classes. 
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